home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20000824-20010305
/
000169_news@columbia.edu _Fri Dec 29 21:42:38 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
7KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA14352
for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 21:42:38 -0500 (EST)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA05809
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 21:42:36 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id VAA28021
for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 21:24:43 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: r@your_host.com (cLIeNUX user)
Subject: Re: Converting struct tm to time_t
Date: Sat, 30 Dec 2000 02:23:17 -0000
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <t4qholhk7rbt30@corp.supernews.com>
To: kermit.misc@columbia.edu
fdc@watsun.cc.columbia.edu...
>In article <92i02v$m4u$1@news01.si.uniovi.es>,
>Igor Sobrado <sobrado@string1.ciencias.uniovi.es> wrote:
>: Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
>: > In article <3A4BA47C.53C64EBA@srv.net>, Kevin Handy <kth@srv.net> wrote:
>: > : Frank da Cruz wrote (about mktime()):
>: >
>: > 2. Doesn't do what you want. "In addition to computing the calendar
>: > time, mktime() normalizes the supplied tm structure" -- applies
>: > timezone conversions, etc. The problem there is, of course, we
>: > don't know, and have no way to find out, the server's timezone, and
>: > even if we knew it, what the rules are to convert to our own. The
>: > struct tm is *already* in GMT/UTC, and should not be converted to
>: > it again.
>: >
>: > Thus the resulting file date won't be what you want. I think the
>: > object of copying the server's MDTM is so update can work in both
>: > directions. If we use mktime(), I think the result will have up to 24
>: > hours of randomness added or subtracted. Am I missing something?
>:
>: As you noted, the FTP-server provides the time in UTC/GMT, all
>: Unix boxes work with that standard convention. The second (incorrect)
>: conversion to UTC is made locally by the host where C-Kermit
>: is installed because mktime(3C) supposes that the tm structure is
>: in local format, not it UTC. Why not calculate the UTC offset for
>: the time (as if it is in local format) and "correct" the time
>: either before converting it to a time_t structure or after that?
>:
>This leads only to more difficulties. The time-related APIs are the most
>twisted and crazed ones in UNIX, and vary significantly from platform to
>platform and version to version of the OS, C library, and compiler and
>header files. How do you find out the timezone or GMT/UTC offset? Is it
>an API call (gettimeofday() or what?), a global long, ulong, int, short,
>etc? A global struct timezone? And/or is it extern time_t tzoffset? A
>member of struct tm? Obtained how? And what are the units? And can you
>believe them? Do they or do they not account for daylight savings time?
>If not, how do we compensate? Here's a typical man page quote:
>
> The external long variable timezone contains the difference,
> in seconds, between GMT and local standard time (in PST,
> timezone is 8*60*60). If this difference is not a constant,
> timezone will contain the value of the offset on January 1,
> 1970 at 00:00 GMT. Since this is not necessarily the same as
> the value at some particular time, the time in question
> should be converted to a tm structure using localtime() and
> the tm_gmtoff field of that structure should be used. The
> external variable daylight is non-zero if and only if Day-
> light Savings Time would be in effect within the current
> time zone at some time; it does not indicate whether Day-
> light Savings Time is currently in effect.
>
>This would not be encouraging even if it applied to every platform,
>but it's only for one release of one OS. In many OS's (e.g. BSDI) the
>variables and structs stay the same but their meaning changes from one
>release to the next. In other OS's the structs and variables change, the
>header files move, and every other manner of obstacle can be expected.
>
>In fact, I can try to program all this, but to make it compile, link, and
>run correctly on hundreds of platforms is not going to be pleasant, as you
>can already tell by looking at the other time-related code in cku[ft]io.c.
>
>If anybody has any helpful or simplifying suggestions, I'd be glad to
>hear them. The question is:
>
> How to convert a struct tm (which already is expressed in GMT) to
> a time_t which expresses the clock time in GMT (not local time) in
> a way that is reliable (works in any timezone and takes daylight
> savings into account) and is portable to as many UNIX platforms as
> possible (and how to do the same things on the platforms to which
> this portability does not extend)? The answer (as noted previously)
> is not mktime(), since it presumes its argument is in local time,
> not GMT.
>
>I'll copy this to comp.unix.programmer.
Daylight savings is an arbitrary political phenomenon. A locale thing.
Plan9 recuses itself from locale issues altogether, leaving them to the
localities, with comments to the effect that no one else can cope. I don't
know if Plan9 is that way about time, but it's the same issue. The
individual Plan9 admins, in this case. I don't deal with the problem in my
little Linux distro either. Even where the tz stuff can be found, it's
horrid. I personally try to keep local non-political time on my box. And
wristwatch.
Oldtimers call what we have now "railroad time". Time used to be relative
to Town Hall or the Cathedral or what-have-you. Technology should at this
point allow us to move back toward that. Let the airlines and the
railroads and networks deal with the diffs, not you and me.
My-wristwatch-local time is of course a fantasy. GPS's are still a bit
large for that :o) Less extreme perhaps is the idea that locale support in
a systems programming language ( C ) is absurd. Plan9 mumbles something
faintly derogatory about software-by-committee concerning POSIX locale
stuff.
Bottom line; see what the problem looks like if you leave daylight savings
to the admin.
Rick Hohensee
www.clienux.com
>
>- Frank